eval、dataset、grader、scorer、harness 這五個詞裡，只有 dataset 是資料，harness 負責跑，grader 和 scorer 負責判，eval 是把它們裝在一起的整件事。位置擺錯，常見的後果是把判斷標準（grading criteria）的問題當成 agent 變差，回頭去改一個根本沒壞的 prompt。

昨天 Toolathlon 那張表看完，接下來就是動手。但動手前這五個詞要先擺對位置，有人拿 eval 指整套系統，有人指一筆測資，而後面每一天都會用到它們。今天沒有新的數字，只有一張圖。

這五個詞各自負責哪一段？

這張圖是這 30 天自己的擺法，不是哪份文件裡的定義，只有 grader 分三種那一格有來源。

Anthropic 那篇談 agent eval 的文章把 harness 的原則寫得很直白：每個 trial 都要從乾淨的環境開始、避免狀態污染（Demystifying evals for AI agents）。前面講過 agent 跑第二次時，輸入的卡已經被上一次改過，這件事就是在 harness 這一層處理的。

這張圖先不管一件事，判的那一邊自己也會判錯，而且兩個方向都會錯，後面會專門講。

grader 跟 scorer 有什麼差？

grader 這個字回答的是「誰來判」。Anthropic 那篇把它分成三種，取捨照它的整理：

• code-based：快、便宜、客觀可重複，代價是對「有效但沒被預期到的變異」很脆，agent 換一個沒想過的正確做法，它照樣判失敗。
• model-based：靈活、抓得到細微差別，代價是非決定性，而且需要人工校準。
• human：品質標準本身，但貴又慢，實務上的位置是拿來校準 model grader。

scorer 在那篇裡沒有對應的定義，所以先講明白：下面這個用法是這 30 天自己的，不是業界共識。 這裡拿 scorer 指 grader 的程式實作，也就是自己建的那支 code，吃期望值跟實際輸出，回傳過或不過，旁邊附上判成這樣的憑證。

所以兩個字是包含關係，每支 scorer 都是 grader（code-based 那一種），反過來不成立，請模型評、請人評都是 grader，但不是 scorer。

為什麼要留兩個字？因為後面會把自己寫的程式跟請來的模型裁判擺在同一個位置比。只用一個字，「把判定方式整個換掉」跟「改一行判定邏輯」會講成同一件事。

位置擺錯，誰會倒楣？

分數掉了，第一個被懷疑的永遠是 agent。但分數是 dataset、harness、grader 跟 agent 四樣一起產出的，前三樣跟 agent 沒關係。

常見的一種錯是把期望值寫進 scorer 的程式裡。它應該跟那筆 case 放在一起，在 dataset 裡；一旦寫進 scorer，加一筆新測資就得改 code，而改的人為了讓新那筆過，很容易順手動到判別邏輯，舊的那幾筆從此判得比較鬆。這種鬆法不會有紅字，分數還在，甚至更好看。

倒楣的是下游，開 PR 的人追一個查不出原因的紅字，改 prompt 的人拿一個測不準的分數當回饋，然後在會議上說「數字沒掉，應該沒事」。判斷標準壞掉跟產品壞掉，在分數上長得一模一樣。

那接下來要處理哪些問題？

前面六天把問題講清楚了：一隻看起來會動的 agent、一行 prompt 改下去就換了個樣子、對一次呼叫寫 assert 為什麼抓不到、公開 benchmark 上的難看數字。

接下來先回答「做對了到底是什麼」。需求方給的驗收標準本身可靠嗎、壞輸入從哪裡找、外部查詢每天回的東西不一樣還能不能重跑、要幾筆才夠。

再往後處理「怎麼讓程式自己判」，以及判斷標準壞掉時長什麼樣。做對一半算不算過、漏報跟誤報哪個嚴重、判斷標準給了滿分但產出是錯的怎麼辦。中間有一題要花幾天講，該不該管它是「怎麼」做到的，官方文件裡「照路徑比對」和「有沒有達成目標」兩種指標都有，沒替你選。

最後把一個人做得到的事變成團隊擋得住的事。怎麼一鍵重跑、哪些動作不准它自己做、幾分才准上線、跑一輪多少錢。

這張圖最後要回答的，還是那一行 prompt 改下去、整理後的卡少標了一個問題卻沒有人發現的事。等 dataset、判斷標準、跑分歷史都在手上，下一次改動當場就看得出來。

明天先處做什麼？

動手的第一步不是開始標資料，明天會先決定「這筆算過」的條件誰負責寫、寫完誰負責驗它。